1. Field of the Invention
The present invention relates generally to World Wide Web servers and, more particularly, to techniques for distributing load among World Wide Web servers.
2. Related Art
Current World Wide Web servers (“web servers”) are accessed by client computers using the Hypertext Transfer Protocol (HTTP) or its encrypted form (HTTPS). A typical interaction between the client computer and a web server consists of several HTTP and/or HTTPS requests. For example, when a user of the client computer first accesses a web site, an HTTP connection request is sent to a web server maintaining the web site. The HTTP request contains a Uniform Resource Identifier (URI) which specifies the web page being requested. The web server, in turn, responds to the HTTP request by downloading the requested web page (e.g., a Hypertext Markup Language (HTML) file) to the client computer. The HTML file is then interpreted by a web browser executed by the client computer and displayed to the user. If the user selects a hyperlink on the web page, a new HTTP/HTTPS request is sent to the web server, which may result in a new web page being downloaded to the client computer.
In addition, the Domain Name System (DNS) protocol is used to translate user-friendly server computer names (e.g., hp.com) into Internet Protocol (IP) addresses (e.g., 191.24.0.2). When the user of a client computer first selects a hyperlink for a web server whose IP address is not already known by the client computer, the client computer uses DNS to obtain the IP address for the web server from a DNS server. Subsequently, the client computer is then able to initiate the HTTP/HTTPS transaction with the web server. DNS servers typically maintain tables mapping names to IP addresses. Included with this mapping is a Time To Live (TTL) value, representing the number of seconds for which a client computer may confidently retain the IP address for a given name once the IP address has been returned through DNS. When a DNS server contains a mapping for a given name, the DNS server is said to be “authoritative” for that name.
In some cases, DNS servers are arranged in a hierarchical fashion (i.e., one DNS server may transfer a DNS name resolution request for a specific name to another DNS server). In these cases, such DNS servers typically do not only contain authoritative mappings, but also temporary, non-authoritative mappings obtained previously via recursion into the DNS hierarchy. These non-authoritative mappings are only retained by the DNS server for such time as permitted by the TTL values.
Since the HTTP/HTTPS protocols are inherently stateless (namely, an HTTP/HTTPS request intrinsically contains no information about the outcome of a prior request), a web server communicating with a client computer cannot rely on these protocols for maintaining state (i.e., storing information about the stage of processing of the client computer's overall interaction with the server). The series of discrete HTTP/HTTPS transactions over which state is maintained is typically referred to as a “session.” As the amount of state data to be maintained increases, or sensitive information is included among it, techniques for exchanging the state data explicitly across HTTP/HTTPS become unsuitable and the state data must be maintained locally on the web server or some other computer (e.g., a database server) to which the web server has direct access. Instead of transferring a large amount of sensitive state data, a small token uniquely referencing the state data is exchanged by the client and server across HTTP/HTTPS, while the state data itself is kept on the server. This general architecture is referred to as “server-resident state,” and the reference token as a “session ID.” Server computers in this architecture are thus referred to as “stateful.”
Server-resident state is typically not a problem when client computers interact with a single server computer. Due to the number of requests received by server computers, however, typically a pool of server computers is used rather than a single server computer. These stateful server computers are referred to as “redundant” in that they are all capable of being used to initiate a session with a client computer. In such a situation, the client computer would ordinarily connect to different server computers in the pool on successive connection requests during a session. This would require sharing the state information for each client among all servers in the pool. This is feasible when the repository for the server-resident state is a shared database or similar resource, or when state data is replicated across multiple repositories. But when the redundant, stateful server computers are remotely located from one another, or the state data is large, or performance considerations outweigh their use, such techniques for sharing server-resident state amongst all of the servers become impractical. That is, in some of these cases, it is impractical for any of the servers in the pool to share state. In other cases, some of the servers in the pool may share state amongst themselves, but not with the others. In any case, each unit of one (or more) redundant, stateful server computers sharing state amongst themselves, but not with other such units in the pool, is referred to as a “site.” Furthermore, the redundant, stateful server computer sites are referred to as “independent” because state data is not being shared among them.
Thus, for a pool of multiple stateful web server sites which are redundant of one another, yet which maintain state independently of one another, the problem arises of distributing sessions across the pool when they are initiated, while maintaining affinity between a particular client computer and server computer site for the duration of a session. The problem is compounded when provision for failure of a server computer site must be made.
A device such as a web proxy may be used to ensure that each client computer always connects to the same redundant, independent, stateful server computer site during a session. Such a system is illustrated by FIGS. 1A–1B. In FIG. 1A, a client computer 110 is connected to a pool of server computer sites 120n (where n=A, B, . . . ) and a web proxy server 140 over a computer-network 130. As illustrated in FIG. 1B, client computer 110 first sends an HTTP/HTTPS connection request to web proxy server 140. DNS server 150 translates the web proxy server name from the URI sent by client computer 110 into a corresponding IP address for web proxy server 140 (IPP). Web proxy server 140, in turn, selects one of server computer sites 120n and sends the connection request along to the selected server computer site 120n. The selected server computer site 120n initiates a new session and responds by downloading the requested web page, including the new session ID, to client computer 110. Web proxy server 140, in turn, maintains a table mapping each client computer 110's session ID to the selected server computer site 120n. As a result, when a new connection request is received from client computer 110, web proxy server 140 is able to forward the request to the selected server computer site 120n using an IP address for a server computer site (e.g., IPA or IPB).
This approach, however, presents several limitations. First, since every connection request is sent to web proxy server 140, web proxy server 140 progressively becomes a performance bottleneck as the number of server computer sites 120n in the pool increases. Similarly, web proxy server 140 creates a single-point of failure for communications directed to the entire pool of server computer sites 120n. 
Finally, session state must be synchronized between web proxy server 140 and the selected server computer site 120n. That is, the web proxy server 140 must recognize when the session of the client computer 110 with the server pool first begins, so that a mapping to the selected server computer site 120n may be added to the table. Similarly, Web Proxy server 140 must recognize when the session has ended or expired, so that the mapping may be removed. Heuristic techniques are typically used to perform session ID recognition. These heuristics, however, are often inadequate for web applications where the session ID changes during a single session, is not removed at the end or expiration of the session, or cannot be recognized due to encrypted transport within HTTPS.
There is thus a need for an improved system for distributing load among web servers.